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■ HOW DO THEY RUN? A 
look at the three common 
mouse interfaces. 



HOW DO THEY RUN? 

Would you describe how the three com- 
mon types of mice work (serial, bus, and 
PS/2 mouse port), how the mouse driver 
communicates with the mouse, and how 
programs in turn talk to the mouse driver? 

Jacek Hejnar 

St. Hubert, Quebec 

Canada 



At the software level, bus mice, 
serial mice, and PS/2 mice are all 
the same. The mouse driver pro- 
vides a common interface so that an 
application program can communicate with 
a mouse using identical sets of function 
calls regardless of its type. 

At the hardware level, however, these 
^nuse types are fundamentally different. 

serial mouse works just like a com- 
munications device: It sends data to the 



serial port of your choice each time a 
mouse event takes place. (A mouse event 
is when a button is pressed or released or 
the mouse is moved.) A microprocessor 
inside the mouse transmits a packet of 
data any time it detects a change in state. 

Typically, the mouse driver programs 
the serial port to interrupt the CPU when 
a byte of data is received at the port. It 
does this in the same way a communica- 
tions program such as ProComm would. 
If the mouse is stationary and no buttons 
are being activated, no CPU time is tied 



MICROSOFT SERIAL MOUSE DATA PACKET FORMAT 




LB RB Y7 Y6 X7 X6 



Byte 2 



Byte 3 



X5 X4 X3 X2 X1 XO 



Y5 Y4 Y3 Y2 Y1 YO 



LB 



RB 



Description 



Not used 
Always 1 
Always 



Lett button 

= pressed 

1 = not pressed 

Right button 

= pressed 

1 = not pressed 



X7-X0 8-bit x-movement indicator (number 

of mickeys moved in the horizontal 
direction since the last data transmission) 

'-Y0 8-bit y-movement indicator (number 

of mickeys moved in the vertical 
direction since the last data transmission) 



Figure 1 : Each time a 
serial mouse is moved, it 
transmits a packet of data 
containing information 
about mouse position and 
the state of the buttons to 
the CPU. This figure 
illustrates the 3-byte data 
packet format that is 
used by the Microsoft 
Serial Mouse and many 
other Microsoft-compatible 
serial mice. 



up tracking mouse actions. 

Many serial mice use the 3-byte packet 
format standardized by Microsoft to trans- 
mit information about mouse position and 
the state of the buttons to the CPU. Figure 
1 shows the format of the packet. Since 
the Microsoft Serial Mouse transmits data 
at 1,200 bits per second using 1 stop bit, 
7 data bits, and no parity, bit 7 (the left- 
most bit) in each byte isn't used. Bit 6 is 
a clock bit that the mouse driver uses to 
stay in sync with the mouse. In the first 
byte in the packet, it's set to 1; in the 
second and third bytes, it's set to 0. Bits 
4 and 5 indicate the current up/down states 
of the left and right mouse buttons. A 
indicates that the corresponding button is 
pressed, while a 1 indicates that it's not. 
The remaining bits in the data packet are 
combined to form two 8-bit numbers in- 
dicating the number of mickeys the mouse 
has moved in the x (horizontal) and v 
(vertical) directions since the last report. 
A mickey is the mouse unit of distance, 
equal to approximately 0.005 inch. By 
recording mickeys, the mouse driver can 
track the location of the mouse at all 
times. 

The mouse driver can determine the 
direction of the movement — up or down, 
right or left — from the sign of the mickey 
counts transmitted by the mouse, which 
are encoded in two's complement form 
(a common method for representing signed 
integers on computers). Using this rep- 
resentation, an 8-bit value can store any 
number from -128 to +127, inclusive. 
Thus, the mouse can move up to 127 
units in either direction (about 0.62 inch) 
in the time it takes a packet to be trans- 
mitted (about 20 milliseconds at 1,200 
bps) without missing a beat. That pro- 
vides enough latitude for you to move the 
mouse across the table rather quickly, 
without losing any information in the pro- 
cess. Some mice use higher data rates to 
increase resolution. Logitech's Series 9 
Mouse, for example, operates at 2,400 
bps, doubling the range that the mouse 
may travel between data transmissions. 
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Not all serial mice use Microsoft's 3- 
byte packet format. The three-button Mouse 
Systems Mouse, for example, transmits 
data in 5-byte packets. The added bits are 
used to transmit information about the 



Fortunately, programs 
don't have to interface 
with the mouse at 
the packet level; 
that's what mouse 
drivers are for. 



third button (something that the Micro- 
soft format does not support) and infor- 
mation about the mouse's current and last 
positions, which, among other things, can 
be used to determine mouse velocity. 

How does the serial mouse get its power? 
It's not battery operated, nor does it have 
to be plugged into an electrical outlet. 
Instead, it draws power directly from the 
serial port through the RTS (request to 
send) line. The Microsoft Serial Mouse 
uses five RS-232 lines: TD (transmit data), 
RD (read data), DTR (data terminal ready), 
RTS (ready to send), and SG (signal ground). 
TD is used to transmit packets of data. 
The driver asserts RTS when it is acti- 
vated, to make sure power is available to 
the mouse, and asserts DTR as a signal 
that it's installed and ready to go. In current 
Microsoft Serial Mouse implementations, 
RD is unused. 

THE BUS MOUSE 

The bus mouse interfacing scheme takes 
an entirely different approach to linking a 
mouse to a PC. Unlike the serial mouse, 
the bus mouse does not contain its own 
microprocessor. Instead, logic on the bus 
interface card is responsible for monitor- 
ing the mouse and notifying the mouse 
driver when the mouse is moved or a 
button is activated. In the most common 
implementation, the card is programmed 
to poll the mouse at regular intervals 
(typically every 1/30 to 1/60 second) and 



interrupt the CPU so that the mouse driver 
can read the current mouse status from 
registers on the card. Why these interrupt 
rates? Because 30 to 60 Hz roughly cor- 
responds to the refresh rates of most dis- 
plays. When the mouse pointer is being 
moved across the screen, there's usually 
no need to poll the mouse more frequently, 
because the screen can't be updated fast 
enough to show what's happening. 

Variations on this basic theme make it 
difficult to paint a picture of how a "typical" 
bus mouse operates. Versions of the 
Microsoft Bus Mouse sold since 1986, 
for example, contain a custom chip called 
an InPort on the bus interface card. This 
chip tracks mouse events and — like the 
microprocessor in the serial mouse — 
interrupts the CPU only when the mouse 
is moved or a mouse button is pressed or 
released. This way, valuable CPU time 
isn't wasted reading registers on the in- 
terface card when the mouse is idle. And 
thanks to the InPort chip, the Microsoft 
Bus Mouse can be programmed for 30-, 
50-, 100-, or 200-Hz operation. It's also 
possible to have the InPort chip interrupt 
the CPU at regular intervals regardless of 
whether there's anything new to report, 
or to forgo interrupts altogether and al- 
low software to drive the mouse strictly 
by polling it. Using this scheme, the mouse 
driver (or a program driving the mouse 
directly) can track mouse position more 
precisely than programmed 30-to- 200-Hz 
interrupt rates allow. Alternatively, it can 
tap into the vertical sync pulse generated 
by the video adapter each time a screen 
refresh is completed and take time out to 
read the mouse status during the vertical 
blanking interval. 

A bus mouse does not send packets of 
data the way the serial mouse does. In- 
stead, status is read directly from lines 
connecting the mouse to the bus interface 
card. For example, the Microsoft Bus Mouse 
uses the nine-pin Hosiden circular con- 
nector shown in Figure 2. Of the nine 
pins, three— SW1, SW2, and SW3— reflect 
the state of up to three mouse buttons in 
real time. XA, XB, YA, and YB carry 
quadrature signals that communicate the 
amount and direction of motion in the x 
and y directions to counter registers in- 
side the InPort chip. In quadrature encod- 
ing, two lines are provided to track mo- 
tion in a given direction. A pulse on one 
of the lines — for example, XA — indicates 
that the mouse has been moved. A pulse 
on XB, which arrives slightly out of phase 
with the pulse on XA, reveals the direc- 



tion of the movement. If XA leads, then 
movement is positive; if the pulse on XB 
comes first, movement is in the negati 
direction. Values read from the InPort » 
counter registers are two's complement 
8-bit numbers, so they, like the values 
transmitted by the serial mouse, may range 
from -128 to +127. 

The remaining two pins on the con- 
nector serve equally important functions. 
The bus mouse draws its power from the 
+5 V pin, while the other pin goes to ground. 

THE PS/2 MOUSE 

The PS/2 mouse is similar to the serial 
mouse in many respects. This mouse con- 
tains its own microprocessor that trans- 
mits clocked serial data to the keyboard 
controller inside the PS/2, just as the 
PS/2 keyboard does. The controller de- 
codes the information coming in and the 
PS/2 BIOS makes it available to the mouse 
driver. Through the BIOS programming 
interface, the mouse sampling rate may 
be set to frequencies ranging from 10 to 
200 Hz. Typically, the mouse driver will 
register itself with the BIOS, and the BIOS 
will activate a handler inside the driver 
each time a mouse-related event occurs. 
One peculiarity of the PS/2 mouse is 



MICROSOFT BUS 
MOUSE PINOUT 




Figure 2: The Microsoft Bus Mouse uses a 
nine-pin Hosiden circular connector to 
interface with the bus interface card. SW1 , 
SW2, and SW3 are used to sense the state 
of the mouse buttons, while XA, XB, YA, and 
YB carry quadrature signals indicating rr- 'se 
movement and direction. The mouse di 
power from the +5V pin, while the remaining 
pin goes to ground. 
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that the packet format it employs does 
not include a clock bit as the Microsoft 
packet does. Furthermore, because the 
same system board controller is used to 
decode data coming from the mouse and 
the keyboard simultaneously, programs 
that use both the mouse and keyboard on 
the PS/2 sometimes experience data-overrun 
conditions that cause the mouse driver to 
lose synchronicity with the mouse. If there 
were a clock bit, timing could be rees- 
tablished and the overrun condition could 
be defeated. Without the clock bit, appli- 
cation programmers have been forced to 
resort to several ad hoc means of main- 
taining the integrity of the information 
flowing to the mouse driver. Some of 
these methods are more effective than 
others. If your mouse goes haywire or 



simply stops working when you run cer- 
tain application programs on a PS/2 
(especially older programs), it's probably 
for this reason. 

It's no accident that you can replace 
the end adapter on a Microsoft Serial 
Mouse and plug it into the mouse port of 
a PS/2. The PS/2 mouse port has six pins, 
one of which carries power to the mouse. 
The Microsoft Serial Mouse looks at this 
line to determine what type of port it's 
connected to and adjusts the format of the 
data it sends out accordingly. If the line is 
asserted (carrying voltage), then the mouse 
knows it's attached to a PS/2 port. If the 
line is not asserted, the mouse concludes 
that it must be attached to a serial port. 

THE MOUSE PROGRAMMING INTERFACE 

Fortunately, programs don't have to in- 
terface with the mouse at the packet level; 
that's what mouse drivers are for. The 
mouse driver is the program you install 



before running an application that uses 
the mouse. The Microsoft mouse driver 
is called MOUSE.SYS or MOUSE.COM. 
(The only difference between the two is 
that MOUSE.SYS is installed with a DE- 
VICE statement in CONFIG.SYS, while 
M0USE.COM is installed from the com- 
mand line or your AUTOEXEC.BAT file.) 
Microsoft and Microsoft-compatible mouse 
drivers provide a set of 35 high-level 
function calls that applications can use 
to communicate with the mouse. These 
functions are summarized in Figure 3. 

For example, if a program wants to 
determine whether a mouse button is 
currently held down, all it has to do is 
make a call to function number 5, Get 
Button Press Information. The driver, which 
fields the interrupt generated when a mouse 
button is pressed or released, keeps track 
of the state of the buttons. In response to 
the program's request, the driver returns 
an integer whose value reflects the cur- 
rent button status. If the left button is de- 
pressed, bit is set to 1 ; if the right button 
is depressed, bit 1 is set to 1. A value of 
in either bit indicates that the corre- 
sponding button is not depressed. 

Mouse driver functions are accessed 
through interrupt 33h. The following code 
sequence portrays what a typical call to 
the mouse driver looks like in assembly 
language: 

MOV AX, 5 

MOV BX, 1 

INT 33H 

TEST BX, 1 

JZ NOT DEPRESSED 



In general, function codes are passed in 
register AX, and other parameters in BX, 
CX, and DX. This particular sequence 
calls function 5 to retrieve the status of 
the right mouse button (BX=1 for the 
right button, BX=0 for the left). On re- 
turn, bit 1 of the BX register is tested and 
a branch is made if it's set to 0, indicating 
the button is not currently depressed. 

We don't have the space here to ex- 
plore each of the function calls in detail. 
For more information, refer to the Micro- 
soft Mouse Programmer s Reference ( 1 989, 
Microsoft Press), or to PC Magazine's 
July 21, 1987, Lab Notes column ("Mouse 
Software: See How They Run," page 
411). However, there is one function that 
is so useful and so widely used by pro- 



MOUSE DRIVER FUNCTION CALLS 



! s nr 

MM 

Code 


Description 







Mouse Reset and Status 




1 


Show Cursor 




2 


Hide Cursor 




3 


Get Button Status and Mouse Position 




4 


Set Mouse Cursor Position 




5 


Get Button Press Information 




6 


Get Button Release Information 




7 


Set Minimum and Maximum Horizontal Cursor Position 




8 


Set Minimum and Maximum Vertical Cursor Position 




9 


Set Graphics Cursor Block 




10 


Set Text Cursor 




11 


Read Mouse Motion Counters 




12 


Set Interrupt Subroutine Call Mask and Address 




13 


Light Pen Emulation Mode On 




14 


Light Pen Emulation Mode Off 




15 


Set Mickey/Pixel Ratio 




16 


Conditional Off 




17 


(Not assigned) 




18 


(Not assigned) 




19 


Set Double-Speed Threshold 




20 


Swap Interrupt Subroutines 




21 


Get Mouse Driver State Storage Requirements 




22 


Save Mouse Driver State 




23 


Restore Mouse Driver State 




24 


Set Alternate Subroutine Call Mask and Address 




25 


Get User Alternate Interrupt Address 




26 


Set Mouse Sensitivity 




27 


Get Mouse Sensitivity 




28 


Set Mouse Interrupt Rate 




29 


Set CRT Page Number 




30 


Get CRT Page Number 




31 


Disable Mouse Driver 




32 


Enable Mouse Driver 




33 


Software Reset 




34 


Set Language for Messages 




35 


Get Language Number 




36 


Get Driver Version, Mouse Type, and IRQ Number 











— 

e 3: Microsoft and Microsoft-compatible mouse drivers provide 35 different function calls 
(functions 1 7 and 1 8 are not assigned) that a program can use to communicate with the 
mouse. Collectively, these function calls make up the mouse programming interface. 
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grammers that a discussion of the mouse 
programming interface couldn't be con- 
sidered complete without it: function 12, 
Set Interrupt Subroutine Call Mask and 
Address. 

Function 12 lets a program instruct the 
mouse driver to interrupt it asynchronously 
when the mouse is moved or a button is 
pressed or released. The program passes 
the mouse driver two objects: a call mask 
and a subroutine address. The call mask 
acts as an event filter. If the program isn't 
interested in mouse movements or button 
releases, the call mask can be set up so 
that the driver interrupts the program only 
when a button press occurs. The subrou- 
tine address is a 32-bit pointer to the 
subroutine that the program will use to 
process calls from the mouse driver. By 
registering itself with the mouse driver 
this way, a program doesn't have to con- 
stantly poll the mouse driver to see what's 
going on. When something happens, the 
program is automatically notified and given 
a chance to act on the event. 



OF MICE AND WINDOWS 

When you run Microsoft Windows, there's 
an additional layer of software placed 
between you and the mouse: the Windows 
kernel itself. With Windows' message- 
based architecture, a Windows program 
doesn't have to make calls to the mouse 
driver to receive information about the 
mouse. Instead, Windows passes the pro- 
gram a message whenever a mouse-re- 
lated event such as the press or release of 
a button occurs. In all, Windows 3.0 de- 
fines 21 different messages that a pro- 
gram may receive from the mouse. These 
messages are listed in Figure 4. 

Of the 21 mouse messages, 10 pertain 
to the client area of the window (the inside 
of the window excluding the title bar, 
menu bar, and scroll bars; in effect, the 
part of the window that a program "owns"). 
In general, a message is transmitted to the 
program's client window procedure when 
the mouse is moved over the client area 
of the window and a mouse button is 
clicked, released, or double-clicked. Win- 
dows passes additional information along 
with the message, including the x- and v- 
coordinates of the mouse pointer at the 
time the event occurs and the state of the 




WINDOWS MOUSE MESSAGES 



Client Area Mouse Messages 
Message name 



Sent when . 




WMJvlOUSEMOVE 

WMLBUTTONDBLCLK 

WMLBUTTONDOWN 

WMJ-BUTTONUP 

WM MBUTTONDBLCLK 



The mouse is moved 

The left mouse button is double-clicked 

The left mouse button is pressed 

The left mouse button is released 

The middle mouse button is double-clicked 



WMJvlBUTTONDOWN 
WM_MBUTTONUP 
WM_RBUTTONDBLCLK 
WM_RBUTTONDOWN 
RBUTTONUP 



The middle mouse button is pressed 
The middle mouse button is released 
The right mouse button is double-clicked 
The right mouse button is pressed 
The right mouse button is released 




bnclient Area Mouse Messages 
Message name 



Sent when . . . 



WM 


NCMOUSEMOVE 


The mouse is moved 


WM 


NCLBUTTONDBLCLK 


The left mouse button is double-clicked 


WM 


NCLBUTTONDOWN 


The left mouse button is pressed 


WM 


NCLBUTTONUP 


The left mouse button is released 


WM_ 


NCMBUTTONDBLCLK 


The middle mouse button is double-clicked 


WM 


NCMBUTTONDOWN 


The middle mouse button is pressed 


WM 


NCMBUTTONUP 


The middle mouse button is released 


WM 


NCRBUTTONDBLCLK 


The right mouse button is double-clicked 


WM 


NCRBUTTONDOWN 


The right mouse button is pressed 


WM 


NCRBUTTONUP 


The right mouse button is released 


WM 


NCHITTEST 


The mouse is moved over any part of the window 



Figure 4: Windows 3.0 defines 21 different mouse messages that can be passed to a 
Windows application. Of the 21 messages, 10 pertain to the client window and 1 1 to the area 
outside the client window. Client-area mouse messages are received when the action takes 
place inside the client window; nonclient area messages are passed when the action occurs 
outside the client window. 



left, middle, and right mouse buttons and 
the Ctrl and Shift keys. 

Nonclient-area mouse messages are 
passed to a window procedure when a 
mouse event occurs inside a program's 
window but outside the client area of the 
window. The nonclient area includes the 
title bar, the menu bar, the minimize and 
maximize boxes, the control menu box, 
the scroll bars, and the window's border. 
In general, these messages parallel the 
client-area mouse messages and even have 
similar names. However, there is one 
nonclient-area message that stands apart 
from the rest: WM_NCHITTEST (Non- 
Client Hit Test). 

This message is passed to the program 
any time the mouse is moved inside the 
program window — inside or outside the 
client area — before any other mouse 
messages are received. It contains the x- 
and y-coordinates of the mouse pointer. 
Normally, programs simply pass this mes- 
sage back to Windows, and Windows uses 
it to generate subsequent messages. 

A program written for Windows may 
choose to act on or ignore any of the 
mouse messages it receives. In fact, it's 
quite feasible (and even common) for 
Windows programs to make extensive 
use of the mouse without processing 
single mouse message. That's because 
Windows takes care of most of the mouse 
processing. For example, when a menu is 
pulled down with the mouse, it's Win- 
dows, and not your application, that re- 
sponds to the mouse click and displays 
the menu. Similarly, when the mouse 
pointer is positioned over a button in a 
dialog box and clicked, the program receives 
notification in the form of a message 
saying an on-screen button was pressed. 

The way software interfaces with the 
mouse depends on the environment in 
which it's being run. All in all, the mouse 
is an amazing little piece of hardware, no 
matter where or how it's being run. 

ASK THE TUTOR 

The Tutor solves practical problems and 
explains techniques for using your hard- 
ware and software more productively. 
Questions about DOS and systems in general 
are answered here. To have your ques- 
tion answered, write to Tutor, PC Magazine, 
One Park Avenue, New York, NY 10016, 
or upload it to PC MagNet (for access 
information, see the PC MagNet Ne-'s 
page immediately following the Uti. 
column). We regret that we're unable to 
answer questions individually. ■ 
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